F-ing applicative functors

Essential to ML-style module systems is the concept of a functor, i.e. a function from modules to modules. Functors are ML’s way of providing generic data structures and reusable program components. Yet, there is a bewildering schism in ML land regarding the actual semantics of functors, familiar to experts under the code words generative vs. applicative. In Standard ML [3], each application of a given functor ‘generates’ fresh copies of all the abstract types the functor defines. For example, two applications Set(Int) of a functor defining an abstract set type will produce two distinct and incompatible instances of this type. For OCaml on the other hand, Leroy [2] suggested a semantics where every application of the same functor to the same argument (under certain syntactic restrictions) reproduces the same type. Consequently, every application Set(Int) would result in the same set type. That is, the functor is ‘applicative’, in the sense that it behaves purely functionally. Applicative functor semantics is more flexible in handling certain modularity scenarios, such as “diamond import” dependencies, where the same functor is used along different paths, without creating type incompatibilities. But it also is far more intricate: